home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / rfc / rfc606 < prev    next >
Encoding:
Text File  |  1991-04-20  |  6.7 KB  |  173 lines
  1. Netork Working Group                                     L. Peter Deutsch
  2. Request For Comments: 606                                       PARC-MAXC
  3.                                                             December 1973
  4.  
  5.                        Host Names On-line
  6.  
  7. Now that we finally have an official list of host names, it seems
  8. about time to put an end to the absurd situation where each site
  9. on the network must maintain a different, generally out-of-date,
  10. host list for the use of its own operating system or user
  11. programs.
  12.  
  13. For example, each of the TENEX sites to which I have access
  14. ( SRI-ARC, BBN-TENEX, USC-ISI, and PARC-MAXC) has a slightly
  15. different mapping between host names and host addresses: none
  16. is complete, and I believe each one differs in some way from
  17. the official List.
  18.  
  19. Since the NIC has responsibility for maintaining the official
  20. list, lt seems appropriate for them to maintain an on-line file,
  21. accessible to anyone, which Lists names and host addresses ( and
  22. certain other information which I will suggest in a moment) in an
  23. easily machine-readable form.
  24.  
  25. This rules out, in my opinion, providing this information only
  26. in the form of an NLS structured file, since there are no
  27. facilities for accessing such files from the network and since
  28. many sites would not want to accommodate themselves to this
  29. structure even if there were.
  30.  
  31. The file I have in mind would be devoted principally to that
  32. information needed by programs, as opposed to people, since the    ;
  33. former want their information in compact, easily parsed form,
  34. whereas the latter appreciate more verbose expression and more
  35. sophisticated facilities for browsing or querying. Therefore, I
  36. propose that the following information be included in such a file:
  37.  
  38. Of course, the official name and host address for each host.
  39. This would be the primary content of each entry.
  40.  
  41. Some information about the options of the various protocols
  42. supported by the host, including ( for FTP ) the preferred byte
  43. size and ( for TELNET) the preferred duplex mode. The former
  44. can have an enormous effect on the efficiency of file
  45. transfers. Since the new TELNET allows negotiation of options,
  46. the list need not be complete or accurate.
  47.  
  48. The function o f the host vis-a-vis the network ( user, server,
  49. TIP, etc.). This may aid NCPs in deciding whether to poll the
  50. host or give useful information for statistical purposes ( e.g.
  51. I would like to make my NCP collect statistics on traffic with
  52. TIPs vs. other hosts).
  53. Since the file will be generated centrally by a single program,
  54. but used widely by a variety of programs, it follows that its
  55. format should be organized for ease of interrogation at the
  56. expense of ease of construction. I feel a reasonable way to
  57. achieve this is to store it as an ASCII text file with the logical
  58. structure of a "property list".
  59.                                    -1-
  60.  
  61. In other words, aside from the two basic facts in each entry
  62. ( name and address), the information will be expressed in the
  63. form of <attribute, value> pairs rather than having the
  64. attribute be recognized by format, position, etc.
  65.  
  66. l don't believe it matters a great deal exactly how this file is
  67. formatted, so I will make a suggestion in the hope that no one
  68. cares enough to protest it. ( This has never worked before in the
  69. history of the network, but it' s still worth a try ) The
  70. following is the proposed syntax of the file.
  71.  
  72. <host-name-file> ::= <entry> | <host-name-file> <entry>
  73.  
  74. <entry> ::= <data-part> <end-of-line>
  75.  
  76. Note that this produces a blank line after the <data-part>.
  77. <data-part> ::= <basic-part> | <data-part> <attribute-item>
  78. <basic-part> ::= <host-name> , <host-address> <end-of-line>
  79. <attribute-item> ::= <attribute-name> = <attribute-value>
  80. <end-of-line>
  81. This leaves the following terms undefined:
  82. <end-of-line>: I don't know what end-of-line indication is in
  83. favor in the network community these days. I personally favor
  84. carriage-return followed by line-feed. TENEX tends to use the
  85. single character octal 37, which is totally non-standard and
  86. inappropriate for this application.
  87.  
  88. <host-name>: an official host name as specified in the recent
  89. RFC 597 (NIC 20826) by NJN and JAKE. It is my understanding
  90. that these names are restricted to letters, digits, hyphens,
  91. and parentheses ( including the network name).
  92.  
  93. <host-address>: a decimal host address, relative to its own
  94. network ( I would assume). There has been no general discussion
  95. of multi-network addressing -- although there is apparently an
  96. unpublicized Internetworking Protocol experiment in progress --
  97. and some other convention may be more desirable.
  98. <attribute-name>: an arbitrary name containing only letters,
  99. digits, and hyphens. We will have to agree on some names like
  100. BEST-FTP-BYTE-SIZE (?), but I am willing to let the NIC pick
  101. them.
  102.  
  103. <attribute-value>: an arbitrary string not containing
  104. <end--of-line>, whose interpretation depends in general on the
  105. attribute. For example, there might be an attribute SERVERS
  106. whose value was a list of the servers customarily run by the
  107. site.
  108.  
  109. The following are some specific attributes that I think would be
  110. worthwhile:
  111.  
  112. NICKNAMES -- value is a list of acceptable nicknames for the
  113. host. Any system that provides name-to-address translation is
  114. encouraged ( although of course not required) to accept these
  115. names as alternatives to the official host name.
  116.  
  117.                                      -2-
  118.  
  119. FTP-BYTE-SIZES -- value is a list of the byte sizes supported
  120. by the FTP server. The first byte size is the one which leads
  121. to the least computational overhead ( e.g. 36 for PDP-1O's, 32
  122. for 36O's).
  123.  
  124. ECHOING -- value is L or R depending on whether the host
  125. expects the terminal to echo ( Remote) or expects to do its own
  126. echoing (Local).
  127.  
  128. Note that no attribute is actually required and that the values
  129. under a given attribute need not be complete. In other words,
  130. this list is meant not to replace option negotiation,
  131. word-of-mouth, or any other means bo which one host discovers
  132. the properties of another, but merely to provide an alternate
  133. source of information which can be accessed in a simple and
  134. uniform way.
  135.  
  136. I realize that there is a time-honored pitfall associated with
  137. suggestions such as the present one: it represents a specific
  138. solution to a specific problem, and as such may not be compatible
  139. with or form a reasonable basis for more general solutions to more
  140. general problems. However, ( 1) this particular problem has been
  141. irking me and others I have spoken to for well over a year, and it
  142. is really absurd that it should have gone unsolved this Long; (2)
  143. no one seems particularly interested in solving any more general
  144. problem.
  145.  
  146. Except the Datacomputer: PLEASE, if there is an easy way to
  147. accomplish the same function through the Datacomputer, someone
  148. write un RFC specifying it.
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.                                        -3-